Processor affinity is a modification of the native central queue scheduling algorithm in a symmetric multiprocessing operating system. Each task (be it process or thread) in the queue has a tag indicating its preferred / kin processor. At allocation time, each task is allocated to its kin processor in preference to others.
Processor affinity takes advantage of the fact that some remnants of a process may remain in one processor's state (in particular, in its cache) from the last time the process ran. Scheduling it to run on the same processor the next time could result in the process's running more efficiently by reducing performance-degrading situations such as cache misses. A practical example might be running multiple instances of an application which does not use multiple threads, such as some graphics-rendering software. Overall system efficiency increases.
Scheduling algorithm implementations vary in adherence to processor affinity. Under certain circumstances some implementations will allow a task to change to another processor if this is deemed to be most efficient. This may be the case if two processor-intensive tasks (A & B) have affinity to one processor while another processor lies unused. Many algorithms would shift task B to the second processor in order to maximize processor use. Task B would then acquire affinity with the second processor while task A would continue to have affinity with the original processor.
Processor affinity can effectively reduce cache problems but it does not curb the persistent load-balancing problem.[1] Further, processor affinity becomes more complicated in systems with non-uniform architectures. For example, a system with two dual-core hyper-threaded CPUs presents a challenge to a scheduling algorithm. There is complete affinity between two virtual CPUs implemented on the same core via hyper-threading, partial affinity between two cores on the same physical chip (as the cores share some, but not all, cache), and no affinity between separate physical chips.
As other resources are also shared, processor affinity alone cannot be used as the basis for CPU dispatching. If a process has recently run on one virtual hyper-threaded CPU in a given core, and that virtual CPU is currently busy but its partner is not, cache affinity would suggest that the process should be dispatched to the idle partner. However, the two virtual CPUs compete for essentially all computing, cache, and memory resources. It would typically be more efficient in this case to dispatch the process to a different core or CPU if one is available. This would likely incur a penalty when process repopulates the cache, but overall performance would likely be higher as the process would not have to compete for resources within the CPU.
On Linux the CPU affinity of a process might be altered with the taskset(1) program.[2] On SGI systems, dplace binds a process to a set of CPUs.[3] NetBSD 5.0, FreeBSD 7.2 and later versions can use pthread_setaffinity_np and pthread_getaffinity_np.[4] In NetBSD, the psrset utility[5] to set a thread's affinity to a certain CPU set. In FreeBSD, cpuset[6] utility is used to create CPU sets and to assign processes to these sets. On Windows NT, thread and process CPU affinities can be set separately by using SetThreadAffinityMask[7] and SetProcessAffinityMask[8] API calls or via the Task Manager interface (for process affinity only). Mac OS X exposes an affinity API that provides hints to the kernel how to schedule threads according to affinity sets.